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witn reference to RFC’s 667, 690, and c92 (NIC %s 32564, 32699, anc 
32734 respectively) py Da Ca talcen, J, Postel], and S. Wolfe 
(resvectively), 1 would like to otter some observations relative to 
current international standarcs recommendations from workina croup 

6.1 of the International Federation cf Information Processing, In a 
meeting nelo last Mav at the NCC, this working craup votec to 

present a recommennation te CCITT (International Consultative 

Committee on Telechony and Telecraphyv of the International 

Teledqraphics Union) for a standard vacket (or DATAGRAM) header. 3 


Tre proposea packet header format is meant to interrace hosts fo 

packet networks, It is not a header for Hosteto-Host protocol, nor 

is it an iMPeto-I4@P neader. The bulk af the header is taken up witn 
adaressing snace (96 pits!) since this vill he compatible with the 
current maximum address space of the telephone system (14 digits) 4 


LOCAL NETWORK FIELE - 4 bits 4a 
This fiela allows local netwerks to operate easily on multiple 
formats, Since the 4 bits can he used in anv fashion aesired 
by the local network. 4al 


DATAGRAM FORMAT = 4 pits åh 


This tield could be used by ARFANET to contain "1061" binary, 
SO as to maintain backnara compatibility with the existina 


message leader format. 4p1 
PACKET TYPE CODE = š bits 4c 
This could be used for the KUST/IMP and LMP/HOST code, 4c1 
FACILITIES =- 16 bits 4d 
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These bits nave not vet been specifically allocated, Some will 

no doubt be for international services (e.0. ftracina at 

gateways between networks, accountina, class of service). It 

was the feeling of bG 6,1 merbers tnat some of these bits 

(e.g. 8) might be allocated to the originatina network (or 
aestination network) for its own use, 4al 


TEXT LENGTH =- 16 bits Ac 


These bits count the number of octets in the text ot the 
packet, not including octets in the nedger (“hich is fixed in 
length for anv particular format). 4e) 


DESTINATION ADDRESS =- 4% bits [1] af 


Tnese bits could be allocated in the tollawing way: 

Destination Network Identifier - 8 bits Destination Host 
Identifier ~ R bits Pestination IMP iacentifier - if brits 

Reserved =- 1b bits 4it} 


SOURCE ADDRESS =- 48 nits 4q 


These bits would be used in a fashion similar ta the 
destination address bits. 4a} 


The resulting packet is 144 bits longa and adding the present 40 bit 
Hosteto-Host header results in a total of 144 bits, which is not 
very pleasant, A temporary fix (until we can introduce a new NCP 
design) might be to squeeze out the reserved 16 bit fields in the 
source and destination address fields, aqivina 32 bits to carry the 
byte size and byte count information for the present Host/Host 
protocol. Alternatively, the length field ot the packet header ana 
one of tne facilities flags (or a whole field) could be used to 
indicate byte size and pvte count. Either idea woulo require some 
fairly substantial modification of existina NCP proarams, so is 
probably not very palatable. 5 


Another alternative would be ta add a dummy byte after the 144th bit 
of header, followed by 40 bits of NCP header, givine a total length 
of message leader and NCP header of 192 bits, a number divisible by 
12, U6, 2a, 32, 48. 6 
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with respect to the broposec text lenath field, altnreugh pit lenaths 
are tne most flexible, it seems reasonable to aamit that nearly all 
data transmission is done in & Pit auantitities, and theretore that 

bit lengths are, in tact, ar unnecessary luxury. This is A weak 

argument when 36 bit and 37 bit machines must interface, 7 


& 


